Spring Cloud与Docker微服务架构实战
周立
Spring Cloud中国社区联合发起人之一，近7年的软件系统开发经验，多年系统架构经验；参与开发多个大型项目，有电信某电信网管项目、某O2O电商平台、某征信系统等；对Spring Cloud、微服务、持续集成、持续交付有一定见地。
热爱技术交流，曾代表公司参加全球微服务架构高峰论坛、QCon等技术沙龙。拥抱开源，多个项目开源在Github与Git@OSC上，并获得开源中国的推荐，例如电子书《使用Spring Cloud与Docker实战微服务》等。
目前，笔者的研究重心是使用Spring Cloud、Docker、微服务，著有《Spring Cloud与Docker微服务架构实战》，已在京东上架。
笔者博客：http://itmuch.com，定期分享Spring Cloud相关博客。
一、为什么要统一管理微服务配置
对于传统的单体应用，我们常使用配置文件管理所有配置。例如一个Spring Boot开发的单体应用，我们可将配置内容放在application.yml文件中。如果需要切换环境，我们可设置多个Profile，并在启动应用时指定spring.profiles.active={profile}。在本书《Eureka Server的高可用》一节，我们使用的也是这种方式。当然，我们也可借助Maven的Profile实现环境切换。
然而，在微服务架构中，微服务的配置管理一般有以下需求：
(1) 集中管理配置。一个使用微服务架构的应用系统可能会包含成百上千个微服务，因此集中管理配置是非常有必要的；
(2) 不同环境，不同配置。例如，数据源配置在不同的环境（开发、测试、预发布、生产等）中是不同的；
(3) 运行期间可动态调整。例如，我们可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不停止微服务；
(4) 配置修改后可自动更新。如配置内容发生变化，微服务能够自动更新配置。
综上所述，对于微服务架构而言，一个通用的配置管理机制是必不可少的，常见做法是使用配置服务器帮助我们管理配置。
二、Spring Cloud Config简介
Spring Cloud Config为分布式系统外部化配置提供了服务器端和客户端的支持，它包括Config Server和Config Client两部分。由于Config Server和Config Client都实现了对Spring Environment和PropertySource抽象的映射，因此，Spring Cloud Config非常适合Spring应用程序，当然也可与任何其他语言编写的应用程序配合使用。
Config Server是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置内容（也可使用Subversion、本地文件系统或Vault存储配置，限于篇幅，本书不作讨论），因此可以很方便地实现对配置的版本控制与内容审计。
Config Client是Config Server的客户端，用于操作存储在Config Server中的配置属性。
图9-1 Spring Cloud Config架构图
如图9-1，所有的微服务都指向Config Server。各个微服务在启动时，会请求Config Server以获取所需要的配置属性，然后缓存这些属性以提高性能。
三、编写Config Server
本节我们来编写一个Config Server。在本例中，我们使用Git作为Config Server的后端存储。
(1) 在Git仓库 中新建几个配置文件，例如：
内容分别是：
为了测试版本控制，我们为该Git仓库创建config-label-v2.0分支，并将各个配置文件中的1.0改为2.0。
(2) 创建一个Maven工程，ArtifactId是microservice-config-server ，并为项目添加以下依赖。
(4) 编写配置文件application.yml，并在其中添加以下内容。
这样，一个Config Server就完成了。
Config Server的端点
我们可使用Config Server的端点获取配置文件的内容。端点与配置文件的映射规则如下：
以上端点都可以映射到{application}-{profile}.properties 这个配置文件，{application} 表示微服务的名称，{label} 对应Git仓库的分支，默认是master。
按照以上规则，对于本例，我们可使用以下URL访问到Git仓库master分支的microservice-foo-dev.properties，例如：
测试
(1) 访问 ，可获得如下结果。
从结果我们可以直观地看到应用名称、项目profile、Git label、Git version、配置文件URL、配置详情等信息。
(2) 访问 ，返回配置文件中的属性：
(3) 访问 ，可获得如下结果：
说明获得了Git仓库config-label-v2.0分支中的配置信息。
至此，我们已成功构建了Config Server，并通过构造URL的方式，获取了Git仓库中的配置信息。
WARNING
需要注意的是，访问 ，结果中类似 的URL并不能访问。这是正常的，因为它并不代表配置文件的实际URL路径，而只是一个标识。有兴趣的读者可前往该页面拓展阅读： 。
四、编写Config Client
前文我们已经构建了一个Config Server，并使用Config Server端点获取配置内容。本节我们来讨论Spring Cloud微服务如何获取配置信息。
下面我们来编写一个微服务，该微服务整合了Config Client。
(1) 创建一个Maven工程，ArtifactId是microservice-config-client ，并为项目添加以下依赖。
(2) 创建一个基本的Spring Boot启动类。
(3) 编写配置文件application.yml，并在其中添加如下内容。
(4) 创建配置文件bootstrap.yml，并在其中添加如下内容。
其中：
：对应Config Server所获取的配置文件中的{application} ；
spring.cloud.config.uri：指定Config Server的地址，默认是 ；
spring.cloud.config.profile：profile对应Config Server所获取的配置文件中的{profile} ；
spring.cloud.config.label：指定Git仓库的分支，对应Config Server所获取配置文件的{label}。
值得注意的是，以上属性应配置在bootstrap.yml，而不是application.yml中。如果配置在application.yml中，该部分配置就不能正常工作。例如，Config Client会连接spring.cloud.config.uri的默认值 ，而并非我们配置的 。
Spring Cloud有一个“引导上下文”的概念，这是主应用程序的父上下文。引导上下文负责从配置服务器加载配置属性，以及解密外部配置文件中的属性。和主应用程序加载application.* (yml或properties)中的属性不同，引导上下文加载bootstrap.* 中的属性。配置在bootstrap.* 中的属性有更高的优先级，因此默认情况下它们不能被本地配置覆盖。
如需禁用引导过程，可设置spring.cloud.bootstrap.enabled=false 。
(4) 编写Controller。
在Controller中，我们通过注解@Value("${profile}") ，绑定Git仓库配置文件中的profile属性。
测试：
(1) 启动microservice-config-server。
(2) 启动microservice-config-client。
(3) 访问 ，可获得如下的结果。
dev-1.0
说明Config Client能够正常通过Config Server获得Git仓库中对应环境的配置。
阅读原文跳转京东购买链接